Content displayed on a web page can be generated by one or more content item servers in response to content item requests that are generated during the rendering of the web page by a client device. The content item requests can be generated synchronously with respect to the rendering of the web page. Likewise, the content items received in response to the content item requests can be processed synchronously with respect to the rendering of the web page. For example, when a web page is rendered, JavaScript may execute and request an advertisement from a first content server. In turn, the first content server may request an advertisement from a second content server. If the advertisement is retrieved synchronously, the rendering of the web page is delayed until a requested advertisement is received from a content server. Once the advertisement is received and rendered, e.g., displayed on the web page, the rendering of the remainder of the web page resumes.
A drawback of synchronous content item retrieval is that if a content item server is slow, then the rendering of the remainder of the web page will be delayed. To mitigate the potential effects of synchronous content item processing, web page publishers attempt to identify the source of the delay, i.e., the content item server that may be slow or temporarily inoperable, and to calculate the total latency times. However, it is often a complex task to compile the multiple HTTP requests and responses from the rendering of a web page in order to calculate the latency times associated with the different servers. For example, the multiple HTTP requests and responses can look unfamiliar, as they do not appear on the web page itself, but are returned by the first content server. Furthermore, if it is determined that a particular server, e.g., the second content server, is the source of the delay, it is difficult to demonstrate the delay to the operator of the second content server.